home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7888 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: EU.net!sun4nl!ittpub!ittpub!nntp
  2. Newsgroups: comp.lang.c++
  3. Subject: Re: Exceptions and operator new. Help
  4. Message-ID: <1996Feb16.174250.1777@ittpub>
  5. From: wil@ittpub.nl (Wil Evers)
  6. Date: 16 Feb 96 17:42:50 WET
  7. References: <4fu14a$2vg@news.tamu.edu>
  8. Distribution: world
  9. Nntp-Posting-Host: lintilla
  10.  
  11. In article <4fu14a$2vg@news.tamu.edu> tpradeep@cs.tamu.edu (Pradeep K  
  12. Tapadiya) writes:
  13.  
  14. > According to the C++ specs, a new will throw a xalloc exception
  15. > if memory allocation fails. 
  16.  
  17. According to the draft standard, it throws a bad_alloc exception.
  18.  
  19. > The return value from new need not be
  20. > NULL. In addition, the constructor can throw a different exception
  21. > as defined by you, the programmer. This means, each time, I do a
  22. > new, I have to do something like 
  23. > 
  24. >    myObject* p = NULL;
  25. > 
  26. >    try {
  27. >      myObject* p = new myObject;
  28. >    }
  29. >    catch (xlloc e) {
  30. >      // do not delete p here since it was never allocated
  31. >      ...
  32. >    }
  33. >    catch (myException& e) {
  34. >       delete p;
  35. >     ...
  36.  
  37. No. The memory allocated will be released when the constructor code throws
  38. an exception as well.
  39.  
  40. > Moreover, if myObject's destructor has to do some
  41. > memroy cleanup, for example,
  42. > 
  43. > myObject::~myObject ()
  44. > {
  45. >    delete [] m_pVarList;
  46. > }
  47. >
  48. > then, the constructor will probably has to do something like
  49. > 
  50. > 
  51. > myObject::myObject ()
  52. > {
  53. >    try {
  54. >      m_pVarList = new char [10];
  55. >    }
  56. >    catch (xalloc e) {
  57. >      m_pVarList = NULL; // explicitly set it to NULL as destructor will
  58. >                         // try to delete a bogus pointer
  59. >      throw xalloc ();
  60. >    }
  61. > }
  62.  
  63. You don't normally have to do this. Assuming your code looks like:
  64.  
  65.     void f()
  66.     {
  67.         myObject *p = new myObject;
  68.         // do things with *p
  69.         delete p;
  70.     }
  71.  
  72. Then, if an exception is thrown in allocating or constructing the new  
  73. object and f() doesn't attempt to catch it, the delete statement is never  
  74. reached. Instead, control will be passed directly to the latest try block  
  75. entered that wants to catch the exception thrown.
  76.  
  77. > Now, setnewHandler adds another variable to the model. As you cannot
  78. > rely on what third party library is doing, anytime you do a new on
  79. > your object, you will explictly have to do a setnewhandler to your
  80. > handler.
  81.  
  82. A quality library probably can be trusted to either install a reasonable  
  83. new_handler or better yet, only use its own new_handler for its own  
  84. dynamic allocation requests. 
  85.  
  86. > Though we have been programming in C++ for quite some time, this is
  87. > the first time our company is venturing out into the world of
  88. > exceptions. It now appears exceptions would make the development process
  89. > more complicated.
  90.  
  91. True, exception handling is controversial. But not for the reasons you  
  92. think it is. The real caveats are far more subtle. Exceptions are not an  
  93. easy subject, and you should probably make sure you understand the  
  94. exception mechanism a bit better before you start using them.
  95.  
  96. In the mean time, you can use the overloaded operator new that takes an  
  97. extra argument of type nothrow. This version will not throw a bad_alloc  
  98. exception on allocation failure, but return 0 instead. 
  99.  
  100. Good luck and best regards,
  101.  
  102. - Wil
  103.   
  104.